문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 티맥스 윈도우 (문단 편집) == 티맥스 윈도우의 실체 == '''일단 (이론만으로는) 실현 가능한 구조이며 확장성도 가질 수 있으나 극단적인 최적화가 이루어지지 않는다면 속도 면에서 매우 비효율적인 구조이다.''' 가장 간단히 말하자면 가장 기본이 되는 [[커널(운영 체제)|커널]]은 Unix-like, 즉 [[POSIX]]를 따르고 있다. 이 POSIX 커널 위에 서브시스템이 돌아가고, 서브시스템 위에 '''리눅스 호환 레이어와 윈도우 호환 레이어, 즉 총 2가지의 호환 레이어가 물려있다.''' 이 두 개의 호환 레이어가 커널과 상호작용하며 바이너리 레벨에서 리눅스, 윈도우의 앱을 모두 호환동작하도록 한다. 즉 본래 OS가 커널과 서브시스템에서 처리하는 것을 티맥스 윈도우에서는 그 상위에 존재하는 호환 레이어에서 동작시키는 것이고, 그걸 커널단으로 넘겨서, 여기서부터 실질적으로 하드웨어와 상호작용을 하게 된다. 사실 티맥스에서 자랑한 마이크로 커널[* 사실 마이크로 커널이란 것은 여러 커널 종류의 하나를 지칭하는 말일 뿐 결코 우월함의 상징이 될 수 있는 것은 아니다. 예전에 수많은 마이크로커널들이 만들어졌다. 점점 도태되어 역사의 뒤안길로 사라진 것만 봐도 알 수 있다. 모노리딕 커널을 비판하고 마이크로 커널이 더 좋다라는 이야기는 1980-1990년대 교과서 수준의 이야기일 뿐, 현대 OS에서 마이크로커널을 쓰는 메이저 OS는 거의 없다.]이라는 것이 어찌 보면 당연한 게, 커널이 정상적인 OS 커널의 기능을 한다기보다는 호환 레이어를 받치는 역할을 하고, 이에 비해 서브시스템이 기존의 리눅스/윈도우보다 비대해져 있으며, 그 결과 이 서브시스템과 호환 레이어가 거의 모든 작업을 다 해먹는다. 실질적으로 커널이 크게 할 짓이 없으므로 작아질 수 밖에는 없고, 당연히 마이크로커널이 탄생한다. 따라서 티맥스에서 주장한 '가상머신(VM)이 아니다'라는 말은 충분히 사실이다. 다만 '''이건 VM 2개(리눅스+윈도우)를 합쳐 커널단을 통합시켜 서브시스템과 호환 레이어의 조합으로 내려놓은 위에서 UI를 돌려버리는 것이라고 생각하는 것이 가장 정확'''할 것이다. 쉽게 말해서, 리눅스에 [[VirtualBox]]로 윈도우랑 리눅스 돌린다고 생각하면 된다. 다른 일면에서 보면, '''속도 문제와 호환성 문제를 해결하면 (이론상) 상당히 발전성이 있는 구조'''라고도 할 수 있다. 하지만 호환성 레이어는 근본적으로 커널이나 서브시스템처럼 하드웨어와 밀접하게 붙어 있지 않으며, 이는 필연적으로 속도를 대폭 저하시킬 수밖에는 없다. (윈도우에서 한두 단계 거쳐서 하던 짓을, 이제는 서너단계에 거쳐서 한다고 생각해 보라. 느리지 않다면 오히려 그게 이상한 것 아닌가?) 결국 윈도우보다 몇 배 효율적으로 코드가 동작하도록 극한의 최적화를 할 수밖에 없고, 그렇게 최적화를 하여야 간신히 원래 윈도우로의 속도가 나오는데, 이것이 될 지는 역시 의문이다.[* 애초에 윈도우 NT 계열도 코드 자체가 극도로 최적화되어 있어서 현재의 속도가 나오는 것이다. MS에서 그때까지 하루이틀에 OS를 만들어온 것이 아니므로, 그 동안에 축적된 기술과 노하우로 윈도우를 개발한 결과 최적화된 부분은 이미 최적화되어 있다. 마찬가지로 리눅스도, 특히 커널 부분은 코드가 윈도우만큼 비효율적이지 않고 깔끔하다.] 즉, '''속도 문제가 정상적으로 해결될 가능성이 크지 않다'''는 것이다. 호환 레이어를 필수적으로 거쳐 바이너리를 돌린다는 개념은 시간이 지난 지금 [[안드로이드(운영체제)|안드로이드]](리눅스+Dalvik/ART)라는 성공한 플랫폼이 하나 있기는 하다. 하지만 안드로이드는 기존의 플랫폼을 에뮬레이트하는 것이 아니라 스스로 새로운 플랫폼을 만들어냈고, 따라서 호환성이나 속도[* 물론 iOS와 비교할 수 있을 정도나 그 이상의 속도를 만든다는 목표는 있겠지만 여기서 말하는 건 애플리케이션이 부드럽게 보일 수 있는 속도를 말한다. 윈도에선 부드럽게 보이던 화면이나 소리가 내부적으로 두세단계씩 추가적인 계산을 거치면서 프레임 간 딜레이가 의도와 다르게 흘러가면 충분히 부자연스러워 질 수 있는 가능성이 있다.]면에서 어딘가에 끌려가는 게 아닌 애플리케이션이 자신에게 맞추도록 주도하는 입장이다. 게다가 안드로이드는 개념상으로는 모든 앱을 ART 기반으로 만들어 호환 레이어 위에서 구동되도록 하는 게 옳지만 제대로 된 최적화를 바라는 앱은 호환 레이어를 우회하여 네이티브 바이너리로 구동시켜주는 NDK를 사용한다는 게 개그.[* [[안드로이드(운영체제)/문제점]] 참조] 사실상 호환 레이어를 필수적으로 거치도록 하면서, 호환 레이어도 다른 OS의 것을 에뮬레이트하는 것이고, 따라서 본래의 OS에 걸맞은 속도에 버그마저도 1:1로 대응되도록 만들어야하는 호환성[* [[와인(소프트웨어)]] 참조]까지 갖춰야 경쟁력이 나오는데, 그게 과연 될까 하는 문제. 하여튼 결론은, '''[[이론상 최강|이론상으로는 그럭저럭 될 것 같지만 실질적으로 삽질]]'''. 그래도 Wine과 같은 '호환 레이어'가 자본과 인력([[공밀레]])이 투입되어 이런 모습으로도 변화할 수 있다는 것을 보여주는 사례가 될 수 있다고 본다. (일단 자본과 인력이 들어가서 뭔가 좀 더 호환성이 높아지고 '''이론상''' 성능이 향상될 수 있는 가능성을 보여주고 있으므로) 크게 보아 윈도우 호환 레이어의 파생, 발전형의 한 가지라 할 수 있을 것이다. 그런데 어째 요즘에는 이런 방향으로 흘러가고 있다. 티맥스 윈도우보다 훨씬 효율적인 구조이기는 하지만 Docker 는 기본적으로 여러개의 가상 머신을 돌린다는 개념이고 리눅스 에서도 KVM을 이용해 가상 머신을 돌리면 그 위에 윈도우즈, 맥OS 다 돌릴 수 있다. 물론, 둘 다 티맥스 보다는 훨씬 시스템적으로 엘레건트한 방법을 사용하기에 성능 저하조차도 적다. 애초에 X86 CPU들이 가상화를 지원하기 시작한 게 꽤 된 것임을 감안하면 이런 접근이 무작정 틀린 건 아니었다. 다만, [[월화수목금금금]] 하느라 돌기만 하면 된다 마인드로 제작했기에 이런 괴작이 튀어나온 것...저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기